雖然昨天有了「Kerberos 員工日遊樂園版」，對 Kerberos 的機制跟相關攻擊比較有概念了，
但……AD 的常見攻擊可不只 Kerberoasting、Golden Ticket、AS-REP Roasting 這幾個！
今天就來整理一下 AD 常見攻擊的機制跟特徵，跟大家一起把它們搞清楚一點 xddd
這次整理的重點不是「怎麼打」，而是先看懂每個手法成立的條件!!!
知道每個攻擊的成立背景，我們才能更有效率地判斷下一步該往哪個方向走~
畢竟滲透測試是有時間壓力的，
方向走錯，可是會少掉很多寶貴的時間 QQ
當然，在 Information Gathering 階段，能多了解目標環境、多收集一些線索，還是很重要的～
那我們就快來一起認識這些 AD 常見的攻擊手法吧！
Day 17 我們詳細看過 Kerberos 的機制。
但在 AD 裡，其實還有另一個很常見的認證機制——NTLM。
而且我們今天要看的AD常見攻擊手法，剛好兩邊都有份 xddd
所以在正式看 AD 常見攻擊前，我們先快速來一起看看這兩個驗證機制～
| Kerberos | NTLM | |
|---|---|---|
| 驗證方式 | 透過票證進行驗證 | 挑戰／回應（Challenge-Response） |
| 雙向驗證 | ✅ 有 | ❌ 沒有 |
| 主要攻擊 | AS-REP Roasting、Kerberoasting、Golden Ticket | Pass-the-Hash、LLMNR/NBT-NS Poisoning |
| 現在還用嗎？ | ✅ AD 預設優先使用 | ⚠️ 還在使用，但 Microsoft 持續推動降低 NTLM 的使用 |
因為有些老舊系統、應用程式或特定情境不支援 Kerberos，這時候就可能還是使用 NTLM QQ
所以雖然 Kerberos 是 AD 環境中的主要認證機制，NTLM 並沒有直接消失><
所以考量AD攻擊時，NTLM 相關的攻擊面也要一起注意!
進入今天的重點!!! 先來拆解這五招
| 手法 | 拆開面具… |
|---|---|
| Kerberoasting | 「我找到一個有 SPN 的服務帳號，跟系統要它的服務票，再拿這張票回家慢慢猜服務帳號的密碼。」 |
| AS-REP Roasting | 「這個帳號關掉了預先驗證，我不用知道它的密碼，就可以拿到一包資料回家慢慢猜密碼。」 |
| Pass-the-Hash | 「我不用知道你的密碼，我手上有你的 NTLM Hash，在支援 NTLM 的情況下，就可能直接拿這個 Hash 做身分驗證。」 |
| LLMNR/NBT-NS Poisoning | 「有人大聲問『欸誰是 FILE01？』，我搶著舉手喊『我我我！』，讓對方把 NTLM 認證資料送到我這裡。」 |
| DCSync | 「我有了足夠的 AD 複寫權限，就可以跟 DC 要求複寫資料，進一步取得其他帳號的認證資料。」 |
| 手法 | 前置條件 | 利用什麼機制 | 能取得什麼 | 怎麼辨別有機會攻擊 |
|---|---|---|---|---|
| Kerberoasting | 任一可以通過驗證的網域帳號 | 找到註冊 SPN 的使用者服務帳號 → 請求 Service Ticket | 可離線破解的 TGS 資料(如 $krb5tgs$),進一步嘗試取得服務帳號密碼 |
找到使用者帳號註冊 SPN |
| AS-REP Roasting | 只要知道帳號名稱,不需要密碼 | 帳號設定 DONT_REQUIRE_PREAUTH → KDC 不要求 Pre-authentication 就回傳 AS-REP | 可離線破解的 AS-REP 資料(如 $krb5asrep$),進一步嘗試取得帳號密碼 |
檢查 userAccountControl 是否有對應旗標 |
| Pass-the-Hash | 已取得某帳號的 NTLM Hash | 利用 NTLM 的 Challenge-Response 機制,使用 Hash 進行驗證 | 可以該帳號身分嘗試存取其他主機或服務 | 手上有 NTLM Hash,且目標服務使用 NTLM |
| LLMNR/NBT-NS Poisoning | 通常需要跟受害者在同網段 | 名稱解析失敗退回廣播查詢時,攻擊者搶先偽造回應,誘使受害者將認證送到攻擊者 | 受害者送出的 Net-NTLMv2 認證資料 | 同網段,且環境存在 LLMNR／NBT-NS 名稱解析 |
| DCSync | 帳號具有適當的 AD 複寫權限(DS-Replication-Get-Changes + Get-Changes-All) |
利用 AD Replication 機制向 DC 要求複寫資料 | 其他帳號的認證資料,權限足夠時可包含 krbtgt |
檢查目前帳號是否具有相關複寫權限 |
那些我差點搞混的東西:
1. Kerberoasting vs AS-REP Roasting
兩個都利用 Kerberos，但切入點不同：
2. Pass-the-Hash 跟 Kerberos 沒關係
PtH 用的是 NTLM 協定，不是 Kerberos。在特定支援 NTLM 的驗證情境下，攻擊者取得 NTLM Hash 後，可以利用它進行身分驗證，而不需要知道原始密碼。
Pass-the-Hash 的核心前提:目標認證流程必須使用 NTLM(如果走的是 Kerberos，就不是一般 PtH 的使用情境)
3. LLMNR Poisoning 是「守株待兔」
不是主動打進去，而是等——等別人的電腦找不到主機名稱，廣播出來問「有沒有人知道這台在哪」，攻擊者假裝自己是那台機器回應，拿到對方送來的 NTLM hash。
還記得 Day 2 整理的滲透測試八階段嗎?
我們來把這幾個 AD 常見的攻擊／技術對應起來，
這樣之後就比較知道什麼時候該派誰上場 xddd
| 攻擊／技術 | 主要落在哪個階段 | 為什麼 |
|---|---|---|
SPN 列舉（GetUserSPNs 不加 -request） |
② Information Gathering | 先把機器的樣子拼出來：哪些帳號有 SPN、有哪些服務帳號值得進一步看 |
| AS-REP Roasting | ③ → ④ | 先找出沒有要求 Kerberos Pre-authentication 的帳號，再取得可離線破解的資料 |
| Kerberoasting | ③ → ④ | 先找出有 SPN 的使用者帳號，再取得 Service Ticket 進行後續分析 |
| Pass-the-Hash | ⑥ Lateral Movement | 已經取得帳號的 NTLM Hash 後，拿來嘗試存取其他主機 |
| DCSync | ⑤ Post-Exploitation | 取得足夠的 AD 權限後，利用原本給 DC 之間使用的「AD 複寫機制」，向 DC 要求複寫資料，進一步取得其他帳號的認證資料。 |
我們今天的實作目標 - 用 GetUserSPNs.py 列出有 SPN 的帳號
呼應 Day 2～
滲透測試不是把每個階段各做一次就結束，
而是會根據新取得的資訊，不斷回頭重新判斷下一步。例如：
列舉(②)發現svc-alfresco關了 pre-auth
→ AS-REP Roasting(④) 拿到 hash → 破出密碼登入
→ 回頭再列舉(②) → 找 SPN、找提權路徑
哇!!!我們真的開始把前面學的東西串起來了~~~
這是今天在Forest機器拿到的target ip 10.129.76.247
本日目標:用 GetUserSPNs.py 列出有 SPN 的帳號
實作前 再來一起看一下!!!
還記得Day 15我們有用 GetNPUsers.py，取得不需要預先驗證的帳號，今天要用 GetUserSPNs.py，大家有沒有覺得他們長得有點像><因為......他們都是impacket工具包裡的工具
| 工具 | 攻擊手法 | 目標帳號 | 需要帳密? | 拿到什麼 | 怎麼利用 |
|---|---|---|---|---|---|
GetNPUsers.py |
AS-REP Roasting | 關掉預先驗證的帳號 | 不需要 | $krb5asrep$23$ 格式的 hash |
丟 hashcat -m 18200 離線爆破 → 猜中就拿到該帳號明文密碼,等於多一組可登入帳密 |
GetUserSPNs.py |
Kerberoasting | 有 SPN 的服務帳號 | 需要 | $krb5tgs$23$ 格式的 hash |
丟 hashcat -m 13100 離線爆破 → 猜中就拿到服務帳號明文密碼,而使用者的服務帳號常有高權限,可能直接提權 |
setspn.exe 跟 PowerView 找過 SPN 了嗎?為什麼還要從目標機外再找一次?這三個工具做的事情有點像，但使用情境不太一樣，來一起把它們分清楚~~~
關鍵差別不是功能，而是——我們現在是在網域環境裡查，還是從 Kali 查!
setspn 和 PowerView 通常是在 Windows shell／網域環境中使用；GetUserSPNs.py 則可以人在 Kali，只靠一組有效網域帳密從外部查詢 AD。
| 工具 | 在哪裡跑 | 找什麼 | 用的時機 |
|---|---|---|---|
setspn.exe |
Windows shell 裡 | 所有註冊 SPN 的 AD 物件（含機器帳號，要自己再判斷） | 已經在 shell 裡，想快速查看 SPN |
Get-DomainUser -SPN |
Windows shell 裡（需要 PowerView） | 使用者帳號的 SPN | 想從使用者帳號角度查看 SPN |
GetUserSPNs.py |
Kali 上 | 直接找較符合 Kerberoasting 條件的使用者帳號 | 還沒進 shell、只有有效網域帳密時，從外部進行列舉 |
setspn -Q */*查到的 SPN 會包含機器帳號，
但機器帳號通常使用系統管理的長隨機密碼，因此一般不是 Kerberoasting 優先考慮的目標。Kerberoasting 通常會優先關注註冊 SPN 的使用者服務帳號。
所以用setspn查完之後，還需要自己判斷哪些帳號值得進一步看~GetUserSPNs.py則會幫我們把結果篩成更接近 Kerberoasting 目標的使用者帳號!
不是每次拿到帳密都能直接進 shell。
有可能：
這些情境的共通點是——我們有「網域層級」的身份，但沒有「某台主機」的登入權。
而 Kerberoasting 的前置條件之一，是有一組可以通過網域驗證的帳號
不需要先取得目標服務帳號的密碼，也不需要先登入某台主機。
這也是為什麼 Kerberoasting 的切入點，可以比「先取得某台主機的 shell」更早~
這時候，即使還沒有 shell，只要手上有一組有效的網域帳密，就可以先從外部做 AD Enumeration><
** 等等Day 17 的 Get-DomainUser -SPN 有找到 krbtgt，但 GetUserSPNs.py 顯示 No entries found!???為什麼???**
GetUserSPNs.py 的查詢會排除停用帳號、電腦帳號等條件，所以像 krbtgt 這種停用帳號，通常就不會被列出來～
GetUserSPNs.py的查詢條件會把停用帳號、電腦帳號等排除，留下可用的使用者帳號!krbtgt 預設是停用狀態，所以通常不會出現在結果裡~
兩個結果看起來不一樣，但結論一樣：Forest 沒有真正適合 Kerberoasting 的目標。
GetUserSPNs.py 不就夠了嗎?不知道大家有沒有跟我一樣，看到這裡腦袋先浮出一個問題 xddd
「都已經有
GetUserSPNs.py可以找 Kerberoasting 目標了，為什麼還要從目標機器列舉 SPN?」
查了一下資料的我 xddd，才發現——
這幾個工具雖然都可以看到 SPN，但目的不太一樣。
GetUserSPNs.py：專門用來列舉具有 SPN 的使用者帳號，方便快速找出可能的 Kerberoasting 目標。Get-DomainUser -SPN / setspn.exe：比較偏向 AD 列舉，讓你從網域內部了解「有哪些帳號設定了 SPN、這些 SPN 對應什麼服務」。所以進到 shell 之後，再列舉一次 SPN，不只是為了找 Kerberoasting 目標。
你是在多了解一點整個 AD 環境：
哪些帳號有 SPN?
哪些服務正在使用?
有沒有奇怪或不合理的設定?
這些資訊之後也可能拿來搭配 BloodHound 做分析，幫助我們理解整個環境裡的關係，以及可能的攻擊路徑。
簡單記:
GetUserSPNs.py
↓
比較偏向「找 Kerberoasting 目標」
setspn.exe / Get-DomainUser -SPN
↓
比較偏向「了解 AD 裡的 SPN 設定」
所以不是 GetUserSPNs.py 不夠，而是——
你站的位置不同，想回答的問題也不同。
Get-DomainUser -SPN 只有攻擊者在用嗎?其實不是!!!
管理員跟攻擊者都可能使用這類工具，只是目的完全不同。同一份 SPN 清單，兩種人看出來的東西天差地遠><
| 👨💻 管理員 | 🕵️ 攻擊者 | |
|---|---|---|
| 目的 | 稽核、確認設定正確 | 偵察、找攻擊目標 |
| 會做什麼 | 查哪些帳號有 SPN、找出不再使用的 SPN、檢查服務帳號設定 | 了解 AD 環境、找出有 SPN 的帳號、鎖定 Kerberoasting 目標 |
| 同一個問題 | 「這些 SPN 設定得對不對?」 | 「這些 SPN 哪個可以打?」 |
其實就很像 nmap～
管理員可以拿來掃自己的網路，了解有哪些服務!攻擊者也可以拿來偵察目標~
這也是我覺得學 AD 滲透很有趣的地方 xddd
很多東西不是「攻擊者專用工具」，而是原本就存在於 Windows / AD 管理環境中的功能，只是到了不同情境，使用方式跟目的就不一樣了!!!
在 Kali 上跑，用Day 15爆破得到的帳密：
GetUserSPNs.py htb.local/svc-alfresco:s3rvice -dc-ip 10.129.76.247
| 指令 | 用途 |
|---|---|
GetUserSPNs.py |
我們的工具!我們請他幫我們找「有 SPN 的帳號」 |
htb.local/ |
網域名稱，跟我們的工具說「我要查 htb.local 這個網域」 |
svc-alfresco |
我登入用的帳號(冒號前面) |
s3rvice |
這個帳號的密碼(冒號後面) |
-dc-ip 10.129.76.247 |
DC 的 IP，要跟它要資料嘛，總得知道它在哪 |
沒有 QQ
跟 Day 17 setspn.exe 跟 Get-DomainUser -SPN 的結論完全一樣——三個工具、兩天操作，都確認了同一件事：Forest 沒有適合 Kerberoasting 的目標。
svc-alfresco 沒有 SPN，其他的不是機器帳號就是 krbtgt，密碼都不好破解，所以這次沒有適合拿來做 Kerberoasting 的服務帳號QQ
所以這次 Forest 的攻擊路徑不走 Kerberoasting
今天讀 Kerberoasting 是學觀念——在其他 AD 環境如果遇到符合條件的服務帳號，到時候就用得上了 xdd
本來面對這麼多名詞，整個霧颯颯 😵，但經過昨天先搞懂認證的原理、加上實作，今天再回來做比較，終於比較了解了，好感動!
尤其今天能把這麼多複雜的機制一個個拆解、想通它的原理、想清楚「我們到底想達成什麼目的」，這種感覺真的很好~ 我想這對之後要真正動手使用的時候，會很有幫助!
回頭看發現：
先懂「認證的運作機制」，再思考「攻擊怎麼成立」，真的比較不卡了!!!
耶～～～
明天是我們 AD 部分的最後一天——我們一起用 BloodHound 把整個攻擊路徑視覺化 👀
iThome鐵人賽
看影片追技術